Operators use different middlebox services or appliances, called inline services, such as deep packet inspection (DPI), logging/metering/charging/advanced charging, firewall (FW), virus scanning (VS), intrusion detection and prevention (IDP), network address translation (NAT), etc., to manage subscribers' traffic. These services have high requirements on throughput and packet inspection capabilities. They can be transparent or nontransparent to the end users. Inline services can be hosted in dedicated physical hardware, or in virtual machines.
Service chaining is required if the traffic needs to go through more than one inline service in a specific order. Moreover, if more than one chain of services is possible, then the operator needs to configure the networking infrastructure to direct the right traffic through the right inline service path. Further, a given chain type may be repeatedly implemented in multiple chains for scaling purposes. In this specification, traffic steering refers to leading the traffic through the right inline service path through selecting a specific instance of a chain of service within the network.
There have been some efforts to determine how to steer traffic to provide inline service chaining. The mechanisms developed through those efforts generally involve computation intense processing through network devices hosting the chains of services.
FIG. 1 illustrates an example of inline service chaining for a data network. In network 100, it is assumed that regular residential traffic flows from resident 152 needs deep packet inspection (DPI) service, DPI 191, and network address translation (NAT) service, NAT 197. Premium residential traffic flows from resident 152 receives the same services in addition to firewall (FW) service, FW 195, and virtual scanning (VS) service, VS 193. Enterprise traffic flows from office 154 do not require service NAT 197, but they do need services DPI 191, FW 195 and VS 193. In this example, all traffic flows go through DPI 191 first at task box 1, and then the traffic flows go back to bounder network gateway (BNG) 102. At task box 2, BNG 102 directs the traffic flows to respective right next hop services such as VS 193, FW 195, and NAT 197 depending on the service sequences of the traffic flows.
The subscriber session authentication, authorization, and accounting (AAA) driven policy can define the first hop service at AAA 112 associated with BNG 102; however, this subscriber context information is no longer associated with the returned traffic from the DPI 191 after task box 1. Hence, determining the next service for a specific flow becomes non-trivial.
One approach to providing services to a network is to use a single box that runs multiple services. This approach consolidates all inline services into a single networking box (e.g., a router or a gateway) and hence avoids the need of dealing with inline service chaining configuration of the middleboxes. The operator adds new services by adding additional service cards to the single networking box.
The single box approach cannot satisfy the openness requirement as it is hard to integrate existing third party service appliances. This solution also suffers from scalability issues as the number of services and the aggregated bandwidth is limited by the capacity of the single box. Also, the number of slots in the chassis of the single box is limited.
Instead of a single box, newer approaches distribute services across multiple network devices within the network. FIG. 2 illustrates another example of inline service chaining for a data network. Network 200 contains ingress nodes IN1 and IN2 at references 252 and 254 respectively, and it also contains egress nodes OUT1 and OUT2 at references 256 and 258, and regular network nodes N1-N4 at references 202-208 respectively. All ingress/egress and regular network nodes are network devices. One difference between ingress/egress nodes (often referred to as edge nodes) and regular network nodes is that ingress/egress nodes receives and transmit frames in and out of network 200.
In network 200, services S0-S2 (which may be DPI, VS, FW, NAT services illustrated in FIG. 1 or any other services) at references 295-297 are distributed to network devices N1, N3, and N4 at references 202, 206, and 208 respectively. Note the distributing of services to network devices may be in a variety of forms. The services may be physically residing at the network devices so that traffic is forwarded to a particular network device to be served by a particular service. The services may be only virtually associated with the network devices and traffic is forwarded to a virtual port associated with a network device for a particular service. Network manager 250 may manage network 200 thus coordinate traffic (frames) through the network to be served by desired chains of services in one embodiment. In another embodiment, individual network devices determine how to get traffic served by desired chains of services.
In general, the network supports two main functions for service chaining: One is an analyzing function used to analyze incoming traffic and identify the frames that need to be processed by a particular service chain. This function is also referred to as classification. The other is a sequencing function used to encode an ordered list of services (sometimes referred to as appliances or applications, or virtual appliance or applications when virtual hosts runs the appliances or applications) that need to be visited into information that can be used by traffic forwarding function within domains upon which the service resides. The sequencing function is also referred to as chain forwarding functions.
Current solutions for the distributed inline service chaining either require physical construction of unique service chains resulting in unreasonable cost and inefficiency. Alternatively, a more contemporary approach is to apply a heavy processing functionality of the analyzer function on every step of the service chains path while having a light processing functionality of the sequencing function that go little beyond identifying the next service in the chain (for example, as applied in OpenFlow protocol). This kind of approach carries a very complex packet processing at each hop of incoming frames, and it is expensive and hard to scale too. Thus, more efficient mechanisms to support service chaining are desirable.